The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
The Simple Network Management Protocol (SNMP) is a network protocol for exchanging network management information between network systems. The current version of the Protocol Operations for SNMP, version 2, is defined in RFC3416 published by the Internet Engineering Task Force (IETF) in December 2002. According to the SNMP specification, network management information is exchanged in data units called Protocol Data Units (PDUs). Some of the PDUs defined in RFC3416 include GetRequest-PDU, GetNextRequest-PDU, GetBulkRequest-PDU, Response-PDU, SetRequest-PDU, InformRequest-PDU, SNMPv2-TrapPDU, and Report-PDU. The PDUs are included in messages exchanged between SNMP management systems and network elements that execute SNMP agents. For example, an SNMP management system, executing on a system connected to the network, requests in a message including a GetBulkRequest-PDU, network information from an SNMP agent that is executing on a network element which might be the same or a different system. The SNMP agent receives the message with the GetBulkRequest-PDU from the SNMP management system, retrieves the requested information in a Response-PDU, and returns the Response-PDU in a message to the SNMP management system.
The network management information exchanged over SNMP is usually stored in Management Information Bases (MIBs) that are typically managed by SNMP agents. The MIB is organized as a tree of objects of management information. A specific instance from an object of management information is called an SNMP variable or an object instance. An object in the MIB is identified by an object identifier (OID), and the value of the OID identifies an object instance. An OID value is an ordered sequence of at least two components: an OID prefix identifying an object, and an OID suffix identifying a particular instance of the object. A scalar object is an object that has exactly one instance at any one point in time. A columnar object is an object defined to have zero, one, or more instances at any given time, and usually represents a column in a table object that stores management information. An object instance has a value, and the pairing of the OID name of an object instance and the object instance's value is referred to as an SNMP variable binding (or a var-bind).
An object instance of a scalar object is identified by an OID value whose prefix is the OID of the object and whose suffix is the number zero. For example, the OID value for an object instance of the scalar object “sysUpTime” is “sysUpTime.0”.
Identification of instances of columnar objects that are included in a table object is accomplished through indexing schemes. An indexing scheme uniquely identifies each instance of the columnar object. As an example, consider the “ipNetToMediaTable” table object defined in RFC1213, which was published by IETF in March 1991. The “ipNetToMediaTable” table object has as its columns the columnar objects “ipNetToMediaIfIndex”, “ipNetToMediaNetAddress”, “ipNetToMediaPhysAddress”, and “ipNetToMediaType”. The indexing scheme defined for this table object includes the columnar objects “ipNetToMedialfIndex” and “ipNetToMediaNetAddress”. Referring to the example of an “ipNetToMediaTable” object depicted in FIG. 1A, under this indexing scheme the object instance value of columnar object “ipNetToMediaPhysAddress” in the second row of the table would be identified as “ipNetToMediaPhysAddress.1.10.1.1.2”, where the prefix “ipNetToMediaPhysAddress” is the OID of columnar object “ipNetToMediaPhysAddress”, and the suffix “1.10.1.1.2” is the concatenated combination of the values of columnar objects “ipNetToMediaIfIndex” and “ipNetToMediaNetAddress” for the second row in table object “ipNetToMediaTable”.
SNMP provides the GetBulkRequest-PDU for retrieval in bulk of network management information from a MIB. The GetBulkRequest-PDU includes the following parameters: a non-repeaters counter (N), a max-repetitions counter (M), and a list of OIDs identifying the object instances whose values need to be retrieved. The GetBulkRequest-PDU is processed in the following way: one object instance value is retrieved for each of the first N OIDs in the request, and M object instance values are retrieved for each of the remaining OIDs in the request. As a result, the GetBulkRequest-PDU is useful for retrieving a potentially large amount of information, for example, from table objects in the MIB.
SNMP management systems often would prefer to use a single GetBulkRequest-PDU to an SNMP agent to retrieve all of the data of a table object in the MIB. However, most of the time an SNMP management system is unaware of the number of entries in a MIB table before the system sends a request to the SNMP agent. Thus, the selection of the max-repetitions counter (M) becomes relevant to the effective retrieval of information, especially when the information is stored in large tables. A max-repetitions counter (M) that is too small may cause the SNMP management system to send too many GetBulkRequest-PDU retrieval requests, which in turn would cause a non-optimal utilization of the network bandwidth and unnecessary processing overhead at both the SNMP management system and the SNMP agent.
A max-repetitions counter (M) that is too big may cause an SNMP agent to retrieve, process, and send back to the SNMP management system a large amount of information that was implicitly requested even though it was not wanted. This is known as the so-called “overshoot” problem. In some situations, the “overshoot” problem can cause significant processing overhead at both the SNMP agent and the SNMP management system, and can increase the information retrieval latency. The reason for the “overshoot” problem is that the number of retrieved object instance values is based only on the max-repetitions counter (M), and the GetBulkRequest-PDU processing always attempts to honor this value regardless of whether the end of a table is reached. For example, when M is large and the SNMP management system is attempting to retrieve a table that has only a few entries, GetBulkRequest-PDU processing does not stop at the end of the table, but continues to retrieve, until the value of M is reached or until the maximum allowed size for a Response-PDU is reached, the values of object instances having OID values that lexicographically follow the OID value of the last entry in the table. In other words, GetBulkRequest-PDU processing honors the value M of the max-repetitions counter by retrieving the object instance values for OIDs that follow, in dictionary order, the OIDs specified in the request.
Based on the foregoing, there is a clear need for an SNMP bulk processing technique that effectively optimizes the use of network bandwidth and that addresses the “overshoot” problem.